home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Graphics Plus
/
Graphics Plus.iso
/
general
/
raytrace
/
rayshade
/
ryshd40n.lha
/
Doc
/
StackWatch.doc
< prev
next >
Wrap
Text File
|
1991-06-05
|
7KB
|
154 lines
This is StackWatch. I wrote it because no one else did.
Legal Stuff
StackWatch ⌐ 1990 by James R. Locker. All rights reserved. Feel free to
redistribute this program so long as you don't modify it, you don't
profit by it (except a reasonable disk copying charge), and you do
include all the documentation. No shareware fee is requested, but I
never turn down a contribution.
FIRST A WORD FROM OUR SPONSOR
VIDEO PROFESSIONALS...Control any Amiga application (such as an animation
or titling program) through the Amiga's second gameport, from a GPI
controller, or from any other external device that can provide a switch
closure. Automatically synchronize your animations with another source.
Reduce your workload. Let the Amiga do the work for you.
Contact:
Jim Locker
Integral Systems Co.
P.O. Box 31626
Dayton, Oh 45424
(513) 237 8290
for information about VidControl and MasterControl.
HANDICAPPED USERS...operate the Amiga WITHOUT A KEYBOARD. KeyWhiz (tm)
enables keyboard input to any application using only a joystick or other
custom input device connected to the second gameport. The entire Amiga
keyboard is supported, and operation is transparent to the application.
Contact Integral Systems Co. for information.
AND NOW ON WITH THE SHOW
What StackWatch does is quite simple. It monitors the stack of the task
or process that you select. It will try to run about 30 times per
second, so it will look at your stack frequently. This enables you to
keep a pretty good ongoing record of how you are doing, stack-wise. It
is much faster about updating then, for instance, Xoper. This is because
its purpose is different than Xoper's and it is dedicated to one job and
only one job. It seems to do that one thing fairly well.
The Amiga is a very stack intensive machine. If you do not provide
enough stack for your routine, you will encounter intermittent crashes
and peculiar behavior. Unfortunately, the operating system doesn't tell
you when you run out of stack, and most applications don't check their
own stack (although some do...StackWatch, for instance, does not watch
its own stack.)
If you set your stack up to a huge number, you will probably be safe, but
you are also wasting memory. What is needed is a good way to tell,
dynamically, how any program is doing. You may then tailor your stack
allocations to be more efficient.
StackWatch helps you with this.
Using StackWatch
StackWatch starts from CLI only. It requires one command line argument,
which is the name of the task or process to be monitored. This name must
be entered EXACTLY as it is maintained in the system task lists.
StackWatch is case sensitive, so if you use an upper case letter while
the system knows the task by a lower case letter, it won't work.
The syntax is as follows:
StackWatch MyTaskName <RETURN>
For instance,
StackWatch Scribble!
will monitor Scribble!.
StackWatch will find Workbench or CLI applications. An application
started from Workbench will have the exact name shown on the icon. An
application started from CLI may be known by a number of different names,
depending upon how it hooks itself into the system. For instance, if you
start the Calculator utility that is found in the Utilities drawer of the
Workbench disk by clicking on its icon, it will have the name
"Calculator" and typing:
StackWatch Calculator
will get you there. However, if you start Calculator from the CLI, while
your current directory is the utilities drawer, then the routine will be
known to the system according to the exact name (including case) that you
invoked it by. If you invoked it by its full path name - such as
"sys:utilities/calculator", then you must locate it with StackWatch by
typing:
StackWatch sys:utilities/calculator
Some utilities - such as PopCLI and StackWatch - detach themselves from
the CLI that started them. These utilities tell the system what their
name is. StackWatch is known as - you guessed it - StackWatch. PopCLI
has a name that depends on the revision number. If you were to rename
StackWatch - maybe to SW - in order to save typing, it would still tell
the system that its name is StackWatch, and you would have to track it
down by that name.
The point is that you might have to figure out what name the system knows
your intended target by. This effort is facilitated by using the utility
Who - which I have provided in this archive. I did not write it, but it
is useful and it will help you with StackWatch.
The StackWatch Window
Has four lines and a "gas gauge". The first line tells you what process
(or task) StackWatch is monitoring. This is useful if you are running
multiple copies of StackWatch. The second line tells you what the stack
allocation for that process is. The third line tells you what the
largest amount of stack used was at any time since StackWatch was
invoked. The fourth line tells you what the stack usage is right now.
Below the text is a graphic display. This "Gas Gauge" tells you - with a
picture - how much of your stack allocation you are currently using. It
also has a peak indicator that tells you what your peak stack usage has
been . The peak indicator may move toward the right of the display, but
it never comes back to the left. It is a "high water mark". The "Gas
Gauge" will indicate stack overflows - if the color bar slops out of the
box on the right, you have overflowed your stack. You may or may not
crash, but it might be a good time to save any critical work in progress.
StackWatch limitations
Stackwatch takes "snapshots" of your process - it is not looking
continuously. Therefore, it won't necessarily spot a quick peak in stack
usage. Caveat Emptor.
StackWatch hooks itself into the system at priority 10, and wants to run
at frequent intervals. One of the first things it does when running is
disable multitasking so it can safely wander through the system Task
lists. As a consequence, under certain circumstances, or if multiple
copies of StackWatch are running, it can noticeably slow system response.
I thought about providing a command line option to change the default
priority, but decided not to. Maybe in the next release.
Future upgrades
May or may not occur. If they do, we might go shareware...how many
people are interested?
I would add Workbench startup, with an Intuition Requester that would
display all the current tasks in the system and allow you to pick the one
you wanted - this in lieu of a command line argument. Might also add a
pull-down menu to let you change tasks on the fly. Currently, you must
close StackWatch and restart it to change tasks. Of course, the
capability to change priorities would be nice.